Design Master - A Visual Program Design Tool review
By Chris Birch
Copyright (c) 1990 Apple Users' Group, Sydney
Republished from Applecations, a publication of the Apple Users' Group, Sydney, Australia.


What requires a pot-pourri of ORCA, APW and MPW assembler, "4380 cigarettes, 68.2 gallons of coffee and 600 hours of Lou Reed to produce"? Not a Satellite of Love, nor a Coney Island Baby but Design Master.
Since its official preview at the 1989 KansasFest (aka Developers Conference) it heralded the promise that, if YOU think you are a good programmer then there is NOW no excuse not to program the IIgs. Here's why.

"Satellite's gone up into the sky..."
Bundled with your IIgs, when you purchase it, is a powerful suite of software known as the Toolbox. It is not a tangible toolbox or manual as such. The Toolbox mostly resides in the computer ("firmware") as well as on your system software disks.
The Toolbox is written and owned by Apple. It contains well over a thousand small programs ("tool calls"), many of which are functionally grouped together into Toolsets. There are tool sets for managing windows, fonts, icons, memory, sound, etc.
Save for the Macintosh, no other computer comes with such a collection of tools for software developers (aka programmers). Their value, in terms of dollars, is worth incalculable times more than the purchase price of a Mac IIfx.

"Oh she's a wild child..."
Design Master (DM) can be thought of as an application which puts these tools to use and makes them more accessible to the developer. Up till now this has proven difficult.
Not necessarily because difficult logic or exceptional ability is required to design and handle windows in a typical application. The problem is that, because of their power, many options are available to the programmer. If you get the options wrong or mixed up, it can be a nightmare to find ("debug") where you went wrong.
Correctly positioning text or controls in a window can also be very time consuming. Each time you nudge a Check Box to the left one pixel, you need to recompile and link your application. You may even have to reboot the system if you really botch things up.
Traditionally, we've had to make a guesstimate as to the correct pixel location to position something on the screen. This included guessing the length of text in pixels. My method was to allow for 7.5 to 8 pixels in width per Shaston character, depending upon the number of capitals, numbers and spaces. Once I got that right I'd set to, centring the string.

"Sugar-plum fairy came and..."
With DM you can adjust the positioning of your window controls interactively. You see the window as you design it because you are actually manipulating the very controls as they are being designed.
No longer do you need to worry about passing all the necessary values to define a menu or window to the Toolbox. DM simply provides you with Dialogs from which you select, with Check Boxes, which options you want.
You could even hit <ENTER> without changing anything and DM will give you a standard default setting. This is good if you are unfamiliar with a particular control or option. You can experiment as you like without fear of causing a system death condition or clobbering your RAM disk.
With DM to handle the setting up of our windows and menus, the built in Memory Manager which makes maximising the RAM resources a trivial task (640K limits with 16K segment size restrictions do not exist in the Apple world), a built in word processor shell (a Toolset all unto itself!), a Task Master to do all the closing, resizing and reporting of what is happening inside the windows and menus automatically (Macs don't have this!) and a state of the art operating system (GS/OS, again better than the Mac's HFS), there is nothing left for the programer to do.
Well, almost. You still need to design the logic of the application. You should be competent with the programming language you are working with. Like an adventure game, the measure of success here is experience, not a high IQ nor a university degree. You'll get it wrong many times, but you'll certainly not improve without trying to get it right.
Essentially though, DM frees up the developer's time to analyse and code the logic behind all the windows.

(love the saxophone solo...)
DM provides the scope to develop an application in an exciting, low cost way. You could use DM, from the outset, to design all your windows and your menus too. If you like, you are basically story boarding the application, just as a movie director or advertising agency would.
As your application grows, you could go back and refine particular windows. Without DM, such story boarding is itself a major task.
This is why DM can be regarded as an important software tool. The ability to prototype, a few years ago, was at the cutting edge of technology for commercial main frame installations.

"Well I'm nowhere at all..."
Superficially, there is nothing much to DM. To get started simply double click on the program icon. If you like the icon (which is contrived and hard to see) place it in the icons folder of your boot volume.
You can get by with only 768K of Ram (I didn't test this) but 1Mb is recommended (tests OK). A second disk drive is recommended, particularly a Hard Disk for serious
development. The Source and Binary folders mentioned in the documentation are useful in an organisational sense but they are not required to be present.
There are just two menus to the right of the usual apple, file and edit menus. The file menu lets you choose what you will be designing - a window, dialog or menu. You can only work on one item at a time.
DM will then step you through any preliminary setting up. You will then be free to select from any highlighted menu item in the Controls menu if you wish to add controls to a window. All the dialogs you will be presented with are minimal and functional. Clearly C. Haun has concentrated on getting DM right, with a minimum of fuss.

"Even though she knew you were wrong..."
The options provided in the dialogs for each control type seem all inclusive. Adding colour is now no longer a process of estimating the correct configuration for a Colour Table (I used to always get it wrong!). You select the colours by clicking on a box containing a splash of the actual colour you want to use. Very civilised.
The Pic and Icon control design tools are very useful. You can accurately load in and clip a picture from disk. No more guess work required. A mini Icon editor is also included. It doesn't let you design a full Finder icon, just the thumb nail sketch to be displayed plus an optional line of text. Quite adequate though.

"glory of love just might come through..."
The Settings menu provides scope to work in a 320 or 640 environment, thus ensuring that your NDA will work in both modes. You can also request alignment grids to be displayed on the Desktop. These are magnetic. Centred cross hairs also help, but it remains that to centre a dialog you must still use some guess work. The same applies to controls in windows. One feature allows the corner coordinates of a control to be concurrently displayed as you are adjusting it. This assists the process of justifying a control enormously.
When it is finally time to put the cat out and save your work, you have a variety of languages to save your output as. All the ORCA/APW languages are supported, as well as Merlin 16+. TML and ZBASIC programmers will be disappointed. You can also save the output as Rez code or as a finished resource.
Note that if you do not additionally save your output in DM's own binary format then you will not be able to continue editing at a later stage.
The ability to generate source code in languages other than ORCA/Pascal was not tested. From a Pascal perspective though, the source code is laid out almost to perfection. You could quibble over the amount of indenting (I prefer 4 over 2) but the alignment of "end"s is always correctly positioned.
All parameter values are given in Hex notation. Given that many of these fields are flags where each bit is significant and all the Apple documentation is in Hex then this makes sense.

BUGS
Before I say another word, I should point out that DM is competing with the Genesys application which had been on the market several months prior to DM. There was considerable pressure on Byte Works to release DM as soon as possible and clearly they could not delay launching DM any longer.
It is my contention that DM was published with known bugs. To their credit, all registered owners are entitled to the next version of DM free. Without the free offer I would be very annoyed and disappointed with the publishers.

"Sally can't dance no more..."
This review could have been published last month but I decided to add a bug report. The bug report blew out to the extent that the entire article would have monopolised Applecations. It is instead available on the AUG Bulletin Board in the Programming draw in compressed format.
DM should be viewed as strictly a prototyping tool. Any code thus generated should also be viewed as such. Check every line of code generated by DM. The errors range from glaringly obvious (Icon controls) to easily overlooked (failure to set bit 13 of the ctlMoreFlags field of pop-up menu controls).
There are also numerous quirks or features missing. These are documented in the above file. One such deficiency is a lack of support for defining the placement of the Tab key in windows with multiple Edit Line controls. IIgs programmers know what I'm talking about here. Suffice to say it's a real chore. DM should address all such chores if it is to succeed as a fully featured prototyping tool.

"Just like Romeo and Juliet..."
This is clearly a very buggy pre-beta release. The "V2.0" in the About... dialog is a ridiculous assertion. Version 0.2a perhaps. I have shown much restraint in my comments in this review. This is because I believe the author is on the right track and he must certainly be encouraged.
That much said, I would rather have DM now and not later. It is a very usable development tool and C.K. Haun should be congratulated. It does succeed in making window and menu design a breeze. It is a giant step forward for the IIgs programming community, just be careful to watch your step though.
If C. K. Haun can kick his habits I'm sure he'll live to release the next version of DM. By then it will be packed with goodies. A resource editor would be a nice feature to incorporate. You do not need to have a nicotine or caffeine addiction to program the IIgs. But a taste for Lou Reed helps.

Design Master - A Visual Program Design Tool
Author: C. K. Haun
Publisher: Byte Works.
Aust. Distributor: None
Purchase direct from Byte Works. Ph: 0011-1-(505) 898-8183. RRP US$95.00. Introductory price: $55.00


THIS CONTENT COPYRIGHT © 2007, APPLE MACINTOSH USERS' GROUP, SYDNEY
Permission has been obtained to make this material available on the Internet.

Permission is hereby granted for non-profit user groups to republish this content.
PLEASE CREDIT THE AUTHOR AND THE SOURCE: Applecations, publication of the Apple Users' Group, Sydney, Australia

THIS PAGE COPYRIGHT © 2007, ANDREW ROUGHAN